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Abstract 


The  advantages  of  systems  of  systems — such  as  the  ability  to  adapt  to  unanticipated  and  unfore¬ 
seen  situations,  eliminate  single  points  of  failure,  and  remain  continuously  operational  while  be¬ 
ing  dynamically  updated — guarantee  their  increasing  importance  to  military  and  commercial  envi¬ 
ronments.  The  advent  of  network-centric  systems  has  served  only  to  accelerate  the  already 
prevalent  move  toward  systems  of  systems. 

At  the  same  time,  network-centric  systems  and  systems  of  systems  are  proving  difficult  to  ac¬ 
quire,  develop,  test,  and  operate.  Many  of  them  are  abandoned  before  they  can  be  fielded,  and 
fielded  systems  often  fail  to  satisfy  their  objectives — demonstrating  cost  and  schedule  overruns  in 
their  development  and  sometimes  catastrophic  failures  in  operation. 

The  increasing  disparity  between  the  normative  (but  nonfactual)  assumptions  that  underlie  current 
practices  and  tools  used  in  the  acquisition,  development,  evolution,  and  operation  of  systems  and 
the  realities  of  actual  systems  of  systems  contributes  to  those  problems.  Effective  practices  and 
tools  for  the  acquisition,  development,  and  operation  of  systems  of  systems  have  not  yet  been  de¬ 
veloped.  Suggesting  a  context  in  which  those  practices  and  tools  can  be  developed,  this  technical 
note  proposes  necessary  conditions — statements  of  what  the  desired  future  state  should  be — in  six 
areas  that  influence  the  effectiveness  of  network-centric  systems  and  systems  of  systems:  (1)  so¬ 
cial  and  cultural  environment,  (2)  legal  and  regulatory  framework,  (3)  management  practices,  (4) 
governance  procedures,  (5)  engineering  practices,  and  (6)  technology  base. 
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1  Introduction  and  Overview 


0  ... 

A  primary  focus  of  the  Carnegie  Mellon  Software  Engineering  Institute  (SEI)  Integration  of 
Software-Intensive  Systems  (ISIS)  Initiative  is  to  improve  the  state  of  the  practice  in  the  acquisi¬ 
tion,  development,  and  operation  of  network-centric  systems  of  systems.  This  technical  note  is 
one  in  a  series  of  papers  leading  to  a  vision  and  research  agenda  for  software  engineering  in  sys¬ 
tem  of  systems.  While  some  earlier  papers  focused  on  the  current  state  of  the  practice,* 1  the  intent 
here  is  to  identify  some  of  the  conditions  that  must  prevail  to  achieve  effective  acquisition,  devel¬ 
opment,  and  use  of  systems  of  systems.2  The  difference  between  current  practice  and  the  neces¬ 
sary  conditions  provides  a  foundation  for  a  vision  and  for  building  a  research  agenda  to  fulfill  that 
vision. 

The  policies  and  practices  that  dominate  all  aspects  of  the  life  cycle  of  traditional  systems  have 
evolved  from  a  number  of  simplifying  assumptions.  Although  never  regarded  as  accurate,  these 
normative  assumptions  have  been  pervasively  adopted  and  have  often  proven  effective  in  the  ac¬ 
quisition,  development,  and  use  of  systems.  The  normative  assumptions  include  clearly  defined 
system  boundaries,  the  ability  to  observe  all  details  within  the  system,  effective  centralized  con¬ 
trol,  hierarchical  management  structure,  fixed  requirements,  a  common  vocabulary  among  partici¬ 
pants,  resource  elasticity,  single  administrative  domain,  the  absence  of  emergent  effects,  and 
small  numbers  of  only  linear  variables  to  be  managed/  Informally,  a  monolithic  system  is  any 
system  whose  characteristics  and  context  closely  match  these  assumptions. 

The  advent  of  network-centric  systems  has  intensified  and  accelerated  the  already  prevalent  move 
toward  systems  of  systems.  The  disparity  between  the  often  unstated  assumptions  that  underlie 
current  acquisition,  development,  evolution,  and  operation  of  systems  and  the  realities  of  actual 
systems  of  systems  leads  to  more  and  more  failures  and  to  reduced  effectiveness  of  systems  as 
they  become  increasingly  network  centric  (see  Figure  1). 


®  Carnegie  Mellon  is  registered  in  the  U.  S.  Patent  and  Trademark  Office  by  Carnegie  Mellon  University. 

1  Earlier  papers  characterize  the  state  of  the  practice  from  a  variety  of  perspectives  [Meyers  2006a,  Smith  2005,  Carney 
2005a,  Carney  2005b,  Carney  2005c,  Carney  2005d,  Lewis  2004b,  Ellison  1997],  Some  related  ideas  are  discussed  in 
other  ISIS  reports  [Brownsword  2006,  Smith  2006,  Meyers  2005,  Brownsword  2004,  Lewis  2004a,  Lewis  2004c,  Morris 
2004,  Christie  2002,  Meyers  2001], 

2  Many  of  the  characteristics  of  network-centric  systems  [Alberts  2003,  Alberts  1999]  and  of  systems  of  systems  [Fisher 
2006,  Moffat  2003,  Fisher  1999,  Lipson  1999]  are  discussed  in  this  report  as  well. 


Some  have  observed  that  commercial  off-the-shelf  (COTS)  products  also  fail  several  of  these  assumptions  and  thus  to  a 
limited  extent  impose  problems  similar  to  network-centric  systems. 
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Monolithic  Systems 


Current  Practices 


'Of, 


Traditional  Monolithic  Assumptions 


Figure  1:  Current  Simplifying  Assumptions  Support  Only  Monolithic  Systems 

Systems  of  systems — with  independent  development  and  independent  management  of  their  con¬ 
stituent4  parts,  continuous  evolution  of  operational  needs,  often-undesirable  emergent  behavior, 
necessity  of  interoperation  with  both  unanticipated  and  legacy  systems,  and  the  need  for  adapta¬ 
tion  to  unforeseen  situations — demonstrate  properties  that  are  in  opposition  to  the  assumptions  of 
traditional  monolithic  systems.5  Systems  of  systems  are  unbounded  in  their  acquisition,  develop¬ 
ment,  and  use.  They  are  unbounded  in  that  regardless  of  where  one  draws  the  boundary,  behavior 
and  success  inside  the  system  will  depend  on  actions  and  conditions  outside  the  boundary.  A 
combination  of  complex  structure  of  dependencies,  multiple  administrative  domains,  the  presence 
of  proprietary  commercial  off-the-shelf  (COTS)  components,  interoperation  with  legacy  systems, 
and  other  uncertainties  guarantees  that  no  one  is  able  to  observe  all  aspects  of  a  system  of  sys¬ 
tems.  Centralized  control  cannot  be  effective  among  parallel  administrative  domains  or  in  con¬ 
texts  where  the  activity  is  invisible  to  the  controller. 

Pretenses  of  centralized  control  aside,  distributed  control  is  inherent  in  systems  of  systems.  Hier¬ 
archical  structures  impose  single  points  of  failure  for  systems  as  a  whole  and  thus  often  can  be 
tolerated  for  noncritical  components,  but  they  should  be  unacceptable  for  systems  of  systems  as  a 
whole.  Real  operational  needs  continuously  evolve  with  change  cycles  much  shorter  than  those  of 
acquisition  and  development.  Systems  of  systems  must  be  tested  without  full  knowledge  of  how 
they  will  be  used  or  with  which  systems  they  must  interoperate.  Misinterpretations  are  inherent  in 
any  communication  and  especially  in  systems  of  systems  where  informal  communication  can  be 
of  critical  importance. 

Resource  limitations  (dollars,  schedule,  or  otherwise)  impose  real  constraints  on  systems  of  sys¬ 
tems  that  often  are  mitigated  through  prioritizing  and  ultimately  shedding  some  capabilities  or 
mission  objectives.  Resource  limitations  are  aggravated  in  systems  of  systems  when  priorities 
differ  among  constituents.  Systems  of  systems  must  cross  administrative  boundaries,  and  attempts 
to  eliminate  such  boundaries  only  aggregate  problems  by  adding  additional  constraints. 


4  We  use  the  term  constituent  to  reference  any  automated,  mechanized,  or  human  element  that  can  act  autonomously 
within  a  system  of  systems. 

5  Our  discussion  of  system-of-systems  characteristics  draws  on  work  done  by  Mark  Maier  [Maier  96], 
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Emergent  behavior  is  inherent  in  systems  of  systems.  However,  only  if  emergent  behavior  is  rec¬ 
ognized  and  influenced  can  its  unanticipated  negative  effects  be  mitigated  and  positive  effects  be 
exploited.  Systems  of  systems  involve  large  numbers  of  nonlinear  variables — a  complexity  that 
cannot  be  understood  and  managed  through  ad  hoc  manual  process  methods  alone;  automated 
tools,  especially  for  modeling  and  simulation,  and  more  formalized  approaches  are  needed. 

Many  advantages  that  derive  from  network  centricity  and  systems  of  systems  are  unachievable 
with  traditional  systems: 

•  Independence  of  management  and  operation  of  constituent  parts  facilitates  adaptability  to 
unanticipated  and  unforeseen  situations.6 

•  Distributed  control  means  that  constituents  act  autonomously  and  in  ways  that  reflect  chang¬ 
ing  circumstances  of  the  mission  and  contribute  to  the  continuing  success  of  the  mission.  (Al¬ 
though  COTS  products  act  independently,  their  actions  are  seldom  influenced  by  the  evolving 
needs  of  a  particular  mission  and  thus  are  potentially  single  points  of  failure  for  the  mission  as 
a  whole.7) 

•  Because  constituents  of  a  system  of  systems  can  dynamically  adapt  to  changes  in  their  envi¬ 
ronments,  it  is  not  necessary  that  constituents  evolve  in  lockstep  or  that  all  changes  be  glob¬ 
ally  coordinated. 

•  Systems  of  systems  are  able  to  exploit  the  increased  communications  bandwidth  to  provide 
large  quantities  of  information  where  and  when  needed. 

•  Increased  interconnectivity  enables  cooperative  operations  with  more  timely  and  reliable  in¬ 
formation. 

•  Systems  of  systems  can  remain  continuously  operational  while  being  dynamically  updated. 
Like  the  proverbial  ax  that  has  had  both  its  head  and  handle  replaced  at  various  times,  a  sys¬ 
tem  of  systems  should  be  able  to  operate  indefinitely  without  interruption  while  undergoing 
incremental  change  that  eventually  replaces  all  of  its  functionality  and  all  of  its  constituent 
technology. 

•  To  be  survivable  in  a  formal  sense,  systems  of  systems  should  be  constructed  not  only  to  be 
resistant  to  single  points  of  failure  but  also  to  any  number  of  failures  that  is  less  than  propor¬ 
tional  to  the  number  of  constituents  [Fisher  1999]. 

The  advantages  of  systems  of  systems  guarantee  their  increasing  importance  to  military  and 
commercial  systems.  At  the  same  time,  network-centric  systems  and  systems  of  systems  are  prov¬ 
ing  difficult  to  acquire,  develop,  test,  and  operate.  Many  systems  of  systems  are  abandoned  before 


6  Independence  and  distributed  control  can  eliminate  unnecessary  constraints  and  enable  loose  coupling  that  is  essential 
to  flexibility  and  adaptability.  As  a  result,  they  allow  systems  to  dynamically  evolve  and  adapt  in  unforeseen  situations.  At 
the  same  time,  they  conflict  with  the  tight  coupling  essential  to  monolithic  systems. 

7  One  example  is  the  Navy  ship  that  went  dead  in  the  water  because  of  a  divide-by-zero  problem  with  a  COTS  product 
[Lutz  2000], 
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they  can  be  placed  into  operation;  when  they  are  put  into  use,  they  often  fail  to  satisfy  their  objec¬ 
tives  and  sometimes  demonstrate  catastrophic  failures. 

The  problem  is  not  that  systems  of  systems  are  necessarily  more  difficult  to  acquire,  develop,  test, 
or  operate;  rather,  effective  practices  and  tools  for  systems  of  systems  have  not  yet  been  devel¬ 
oped  (see  Figure  2).  More  importantly,  whatever  their  details,  those  new  or  improved  practices 
and  tools  will  likely  be  in  conflict  with  current  system  acquisition  and  development  practices  that 
are  built  on  assumptions  that  are  no  longer  valid.  This  problem  exists  not  only  for  modem  net- 
work-centric  systems  of  systems  but  also  for  the  social  systems  that  acquire,  develop,  evolve,  and 
operate  them. 

Improved  Transition  Methods 
(e.g.,  engineering  practices, 
management  practices,  governance 
procedures) 

Current  State 


Normative 
Assumptions 
for  Monolithic 
Systems 


New  Paradigms 

(e.g.,  social  and  cultural  environment, 
legal  and  regulatory  framework, 
technology  base) 

Figure  2:  New  Practices  and  Tools  are  Needed  to  Realize  the  Vision  for  Network-Centric 
Systems  of  Systems 

The  effectiveness  of  systems  of  systems  for  acquisition,  development,  or  operations  is  influenced 
by  not  only  the  structure  and  functionality  of  their  software  and  mechanical  and  electronic  com¬ 
ponents  but  also  their  social  and  cultural  environment,  legal  and  regulatory  framework,  engineer¬ 
ing  practices,  and  governance  procedures.  Systems  of  systems  can  be  analyzed  on  many  dimen¬ 
sions,  and  we  can  set  boundaries  between  dimensions  at  many  places.  The  need  for  a  new 
business  model  that  illustrates  how  developers  or  contractors  can  be  profitable  in  a  system-of- 
systems  context,  for  example,  is  important  but  beyond  the  scope  of  this  report.  The  sections  in  this 
technical  note  describe  necessary  conditions  to  which  the  following  areas  must  evolve: 

•  social  and  cultural  environment  (Section  2) 

•  legal  and  regulatory  framework  (Section  3) 

•  management  practices  (Section  4) 

•  governance  procedures  (Section  5) 
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•  engineering  practices  (Section  6) 

•  technology  base  (Section  7) 

Distinctions  between  network-centric  systems  and  systems  of  systems  are  unimportant  in  this  re¬ 
port.  Network-centric  is  generally  used  to  refer  to  systems  or  activities  that  are  enabled  by  and 
built  upon  large-scale  communications  networks.  Thus,  most  modem  military  systems  of  systems 
are  network-centric  systems,  and  military  operations  are  often  network-centric  operations.  The 
term  systems  of  systems  refers  to  those  systems  that  involve  multiple  independent  decision  mak¬ 
ers,  display  emergent  behavior,  necessitate  distributed  control,  or  are  too  complex  to  be  fully  visi¬ 
ble  to  any  one  entity.  Thus  most  modem  military  systems,  including  network-centric  systems,  are 
systems  of  systems. 

For  our  purposes,  a  system  of  systems  is  a  system  for  which  the  normative  assumptions  of  the 
monolithic  system  deviate  sufficiently  from  the  reality  of  the  system  that  they  are  likely  to  lead  to 
failures  in  acquisition,  development,  testing,  or  operations.  In  contrast,  monolithic  systems,  al¬ 
though  never  satisfying  these  assumptions  in  the  limit,  come  sufficiently  close  in  most  instances 
that  the  differences  can  be  ignored. 
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2  Social  and  Cultural  Environment 


Necessary  Condition 

The  social  and  cultural  environment  in  which  systems  of  systems  are  acquired,  developed,  used, 
and  evolved  motivates  collaborative  behavior  critical  to  achieving  operational  effectiveness. 

Rationale/Basis  for  this  Necessary  Condition 

Success  in  the  acquisition,  development,  evolution,  and  operation  of  any  system  depends  largely 
on  the  social  and  cultural  environment  in  which  those  activities  are  carried  out.  This  condition  is 
especially  true  in  systems  of  systems  where  progress  cannot  be  effectively  dictated  or  assessed  by 
conventional  means;  where  operational  needs  change  continuously,  requiring  system  configura¬ 
tion  and  functionality  to  adapt  rapidly  in  often  unforeseen  ways;  or  where  critical  system  compo¬ 
nents  are  beyond  the  control  of  any  one  organization. 

Discussion 

The  social  and  cultural  environment  of  an  organization,  project,  or  system  emerges  from  the  local 
actions  and  neighbor  interactions  of  all  its  participants  and  largely  determines  how  individuals  and 
organizations  behave. 

The  social  and  cultural  environment  may  differ  among  acquisition,  development,  and  operational 
organizations.  It  also  may  differ  among  organizations  participating  in  any  one  of  these  activities. 
To  the  extent  that  aspects  of  the  social  and  cultural  environment  differ — or  are  in  conflict  with 
each  other — on  critical  issues,  the  acquisition,  development,  or  operation  of  a  system  may  fail  to 
satisfy  its  objectives.  Divergence  among  constituencies  and  organizations  involved  in  a  system  of 
systems  is  more  likely  where  there  is  a  greater  number  of  them  and  each  of  them  is  less  special¬ 
ized. 

The  social  and  cultural  environment  for  a  network-centric  system  must  be  supportive  of  the  inher¬ 
ent  properties  of  systems  of  systems — and  therefore  in  conflict  with  many  of  the  normative  as¬ 
sumptions  that  underlie  the  social  and  cultural  environments  appropriate  for  conventional  mono¬ 
lithic  systems.  For  example,  in  a  traditional  stovepiped  development  of  a  monolithic  system,  the 
ultimate  measure  of  success  is  often  considered  to  be  operational  effectiveness.  Even  though  no¬ 
body  believes  that  contractually  established  requirements  will  represent  real  needs  at  the  end  of 
the  development  process,  systems  are  not  designed  to  facilitate  evolving  requirements,  require¬ 
ments  are  rarely  kept  current  with  evolving  needs,  and  contractors  are  rewarded  for  satisfying  re¬ 
quirements  rather  than  evolving  needs.  In  a  system  of  systems,  end-user  needs  are  continuously 
changing  and  operational  effectiveness  can  be  achieved  only  through  continuous  validation  from 
interaction  with  the  operational  community.  Systems  of  systems  must  be  developed  in  a  social  and 
cultural  environment  in  which  operational  effectiveness  is  accepted  as  a  critical  measure  of  suc¬ 
cess  and  the  dynamic  character  of  the  needs  of  operational  effectiveness  is  recognized. 
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More  broadly,  the  social  and  cultural  environment  must  incorporate  an  understanding  of  the  need 
for  systems  that  are  flexible  and  locally  adaptable  to  unforeseen  situations.  Likewise,  it  must 
strive  not  for  maximizing  satisfaction  of  current  requirements  but  for  continuous  long-term  satis¬ 
faction  of  operational  effectiveness.  The  autonomy  of  constituents  and  distributed  control  in  sys¬ 
tems  of  systems  require  open  communication  and  cooperation  and  a  social  and  cultural  environ¬ 
ment  characterized  by  a  high  degree  of  trust. 

The  current  environment  of  acquisition  and  development — as  defined  by  requirements,  regulation, 
policy,  contracts,  and  tradition — is  founded  on  assumptions,  shown  in  Table  1,  that  although 
known  to  be  inaccurate  prevail  nevertheless.  These  assumptions  suffer  not  only  from  their  inaccu¬ 
racy  but  also  from  a  social  and  cultural  environment  that  counterproductively  strives  to  make 
them  true. 

Table  1:  Inaccurate  Assumptions  Underlying  Current  Environment 

Prevailing  (But  Inaccurate)  Assumptions 

Operational  needs  can  be  known  prior  to  the  start  of  acquisition  and  development  and  seldom  change 
thereafter. 

Requirements  reflect  real  user  needs. 

Someone  or  some  group  is  in  charge  that  has  visibility  into  all  aspects  of  the  development  and  can  ex¬ 
ercise  control  over  any  part  of  the  development  process  when  necessary. 

Stakeholders  understand  the  objectives  and  work  toward  the  same  ends. 

Adequate  money  and  personnel  are  available  to  complete  the  effort. 

Schedules  will  be  met. 

Success  in  all  individual  components  ensures  success  of  the  system  as  a  whole. 

None  of  these  assumptions  is  valid  in  general.  Failure  to  recognize  resource  limitations,  schedule 
conflicts,  and  other  inconsistencies  can  be  problematic  in  any  system.  But  for  systems  of  systems, 
distributed  control  and  independent  decision  making  increase  the  likelihood  of  such  problems. 
Furthermore,  taking  local  actions  within  individual  stovepipes  to  alleviate  resource  limitations, 
such  as  shedding  functionality,  exacerbates  problems.  The  failure  of  any  one  component  to  sup¬ 
port  a  capability  in  this  monolithic  systems  approach  can  eliminate  that  capability  for  the  system 
as  a  whole.  Tradeoffs  among  competing  resources  must  be  resolved  through  consensus  on  consis¬ 
tent  system-wide  prioritization  of  capabilities,  not  through  local  optimization  or  expedience 
within  each  constituency. 

Actions  that  can  encourage  a  culture  supportive  to  systems  of  systems  include 

•  emphasizing  the  critical  importance  of  operational  effectiveness 

•  educating  participants  to  the  distinctive  characteristics  of  systems  of  systems 

•  communicating  the  importance  of  interoperability  to  the  mission 

•  creating  situations  in  which  all  participants  have  a  stake  in  the  success  of  the  system  of  sys¬ 
tems 

•  establishing  cooperative  means  to  build  consensus  and  shared  vision  among  the  stakeholders 
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•  establishing  a  culture  that  looks  for  and  reacts  to  changing  needs 

A  sense  of  belonging,  shared  ownership  in  the  outcome,  elimination  of  unfunded  mandates,  pri¬ 
oritization  of  objectives,  elimination  of  stovepipe  development  and  operations,  and  active  ongoing 
participation  of  operational  organizations  in  tradeoffs  also  can  help. 

Especially  powerful  in  determining  the  effectiveness  of  the  acquisition,  development,  or  operation 
of  systems  of  systems  are  the  reward  systems  as  perceived  by  participating  organizations  and  in¬ 
dividuals.  Local  reward  systems  that  conflict  with  global  objectives  undennine  the  success  of  the 
system  of  systems  as  a  whole.  When  local  reward  systems  conflict  with  one  another,  it  is  often  an 
indication  that  some  of  them  are  poorly  aligned  with  global  objectives.  Reward  systems — whether 
individual,  contractual,  or  organizational — are  beneficial  only  when  they  are  consistent  with 
evolving  operational  objectives.  Rewards  need  not  be  monetary.  Recognition,  budget  allocation  or 
relief,  advantage  toward  participation  in  future  projects,  and  a  sense  of  accomplishment  can  all  be 
part  of  an  effective  reward  system. 

An  effective  social  and  cultural  environment  for  acquisition,  development,  and  operation  of  net- 
work-centric  systems  must  be  composed  of  individuals  and  organizations  that 

•  have  internalized  the  distinguishing  characteristics  and  implications  of  system  of  systems 

•  can  interpret  those  implications  in  the  context  of  the  current  system 

•  are  supported  in  focusing  on  operational  effectiveness  by  an  appropriate  local  reward 
structure 

•  view  success  of  the  enterprise  as  their  individual  responsibility 

•  have  sufficient  current  infonnation  to  know  whether  actions  are  beneficial 

Systems  of  systems  offer  the  potential  for  flexibility  and  adaptability  to  unanticipated  situations 
that  is  impossible  for  monolithic  systems.  Benefits,  however,  accrue  only  through  recognizing, 
understanding,  and  exploiting  system-of-systems  characteristics.  The  social  and  cultural  environ¬ 
ment  must  incorporate  an  understanding  of  system-of-systems  characteristics.  But  it  is  not  enough 
to  know  that  independent  action,  unboundedness,  and  emergent  behavior  are  inherent  or  that  tight 
coupling — through  requirements  for  unneeded  functionality,  burdensome  bureaucracy,  exagger¬ 
ated  promises  or  demands,  or  copious  meetings  with  little  value  from  an  individual  perspective — 
will  undennine  success.  Participants  must  also  understand  how  to  exploit  that  knowledge  to  ad¬ 
vantage  and  achieve  desired  outcomes  with  loosely  coupled  methods.  Through  the  increased 
autonomy  of  individual  participants,  loose  coupling  can  offer  many  advantages  in  quality,  produc¬ 
tivity,  and  cost  over  tightly  managed  hierarchical  structures — but  only  in  a  social  and  cultural  en¬ 
vironment  of  shared  objectives  and  strategy. 

Cooperation,  collaboration,  and  compromise  also  require  a  willingness  to  suffer  suboptimal  local 
solutions  for  the  sake  of  global  optimality.  Global  refers  to  both  time  and  space;  what  is  most  effi¬ 
cient  based  on  current  and  locally  available  information  might  lead  to  inefficiencies  when  later  or 
more  comprehensive  information  becomes  available.  Furthermore,  circumstances  are  continu¬ 
ously  evolving,  so  that  an  optimal  solution  today  can  be  quite  inefficient  tomorrow.  Thus,  a  sys- 
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tem-of-systems  solution  should  involve  continuous  feedback  among  constituents  and  local 
adaptability  to  new  conditions  as  they  become  known,  leading  to  systems  that  are  rarely  locally 
optimal  but  always  tending  toward  global  optimality  through  dynamic  adaptability  [Fisher  2006]. 

The  social  and  cultural  environment  is  a  cumulative  emergent  effect  implicitly  understood  by  the 
constituents  that  emanates  from  their  engineering  practices,  governance  procedures,  and  legal  and 
regulatory  framework — as  well  as  from  the  technology  base,  hardware  and  software  infrastruc¬ 
ture,  and  a  variety  of  other  influences.  At  the  same  time,  the  social  and  cultural  environment  pro¬ 
vides  the  context  in  which  those  practices,  procedures,  and  framework  must  operate.  A  conflicting 
or  nonsupportive  social  and  cultural  environment  will  make  it  difficult  to  achieve  expected  re¬ 
sults. 

A  new  social  and  cultural  environment  characterized  by  trust,  cooperation,  and  shared  understand¬ 
ing  of  evolving  operational  needs  is  needed.  Establishing  an  effective  social  and  cultural  envi¬ 
ronment  will  require  goals  such  as  those  in  Table  2. 

Table  2:  Goals  for  Social  and  Cultural  Environment  that  Supports  Network-Centric  Systems  and 

Systems  of  Systems 

Recommended  Goals 

Clearly  identify  what  environmental  characteristics  are  needed. 

Remove  constraints  that  are  in  conflict  with  those  needs. 

Eliminate  coupling  that  may  preclude  effective  solutions. 

Enable  a  broad  spectrum  of  experimental  approaches  from  which  an  effective  social  and  cultural  envi¬ 
ronment  can  emerge. 

Revise  reward  systems  to  support  evolving  objectives. 

Develop  methods  that  minimize  communication  while  ensuring  that  essential  information  is  available 
when  and  where  needed. 

Establish  conditions  that  encourage  trustworthy  behavior  and  marginalize  the  influence  of  untrustworthy 
participants. 

Although  many  of  these  expectations  and  recommendations  are  not  fully  achievable  today,  they 
provide  goals  that  are  surmountable  in  the  long  run.  In  addition,  each  increment  of  progress  to¬ 
ward  those  goals  reduces  risk  and  increases  the  likelihood  of  success  in  systems  of  systems.  In  the 
short  term,  the  focus  should  be  on  eliminating  those  aspects  of  the  current  social  and  cultural  envi¬ 
ronment  that  serve  as  barriers  to  achieving  necessary  reforms  in  other  areas. 
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3  Legal  and  Regulatory  Framework 


Necessary  Condition 

There  exists  a  legal  and  regulatory  framework  to  support  the  acquisition  of  systems  of  systems. 

Rationale/Basis  for  this  Necessary  Condition 

The  following  dichotomy  exists  within  the  U.  S.  Department  of  Defense  (DoD)  regarding  the  net- 
work-centric  perspective:  The  operational  community  desires  integrated  capabilities  to  meet  a 
mission,  but  the  acquisition  community  focuses  on  delivering  a  system-oriented  solution.  Net- 
work-centric  behavior  must  occur  in  more  than  the  operational  community. 

The  ability  to  acquire  systems  that  are  expected  to  operate  efficiently  in  a  network-centric  context 
is  fundamental.  The  acquisition  process  is  governed  by  many  laws,  regulations,  and  policies — all 
of  which  are  reflected  in  management  practices.  The  current  acquisition  environment  focuses  on  a 

o 

particular  system,  often  at  the  neglect  of  the  larger  perspective.  There  is  also  a  perception,  wide¬ 
spread  in  the  defense  community,  that  the  laws  and  regulations  governing  acquisition  must  be 
revised  to  support  network-centric  principles. 

Discussion 

Our  use  of  the  term  legal  and  regulatory  framework  includes  laws  and  the  many  artifacts  derived 
from  statutes,  such  as  regulations,  policies,  and  directives.  The  acquisition  community  executes 
management  practices  in  the  context  of  the  existing  legal  and  regulatory  framework.  Awareness 
of  the  need  for  change  in  those  management  practices  is  not  new.  For  instance,  in  2001  then  Sec¬ 
retary  of  Defense  Rumsfeld  reported,  “Despite  some  128  acquisition  reform  studies,  DoD  has  an 
acquisition  system  that  since  1975  has  doubled  the  time  it  takes  to  produce  a  weapon  system — 
while  the  pace  for  new  generations  of  technology  has  shortened  from  years  to  18  months”  [Rums¬ 
feld  2002], 

Those  studies  assumed  the  acquisition  of  a  single  system,  the  focus  of  existing  laws.  For  example, 
10  USC  section  2431  (Title  10)  states 

(a)  The  Secretary  of  Defense  shall  submit  to  Congress  each  calendar  year .  .  .  budget  jus¬ 
tification  documents  regarding  development  and  procurement  schedules  for  each  weapon 
system  for  which  fund  authorization  is  required.  .  .  .  The  documents  shall  include  data  on 
operational  testing  and  evaluation  for  each  weapon  system  .  .  . 


8  Alberts  and  associates  write  as  follows:  “Individual  services  and  agencies  currently  acquire  material  and  systems  one  by 
one.  This  approach  needs  to  change”  [Alberts  1999,  p.  228], 
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(b)  .  .  .  documents  required  to  be  submitted .  .  .  shall  include  .  .  .  information  with  re¬ 
spect  to  each  weapon  system  covered  and  shall  specifically  include  .  .  .  development 
schedule,  including  estimated  annual  costs  .  .  .planned  procurement  schedule  ... 
most  efficient  production  rate  .  .  .  most  efficient  acquisition  rate.  .  .  [USC  2004.  em¬ 
phasis  added]. 

Federal  Acquisition  Regulations  (FARs)  and  department  policies  and  practices  (notably  the  Plan¬ 
ning,  Programming,  Budgeting,  and  Execution  process)  also  reflect  a  system-specific  perspective. 
In  turn,  this  perspective  enforces  the  well-known  stovepipe  behavior  of  the  acquisition  system: 
Resources  are  allocated  directly  for  a  single  system  and  are  described  in  its  Program  Office 
Memorandum  (POM).  Consequently,  the  acquisition  community  is  less  able  to  provide  the  inte¬ 
gration  of  systems  that  the  operational  community  seeks. 

To  move  toward  a  different  acquisition  model,  it  will  be  necessary  to  change  many  things,  such  as 
the  resource  allocation  process  noted  previously.  Management  practices  must  not  be  specific  to  a 
particular  program.  Instead,  they  must  take  into  account  the  needs  of  multiple  programs  and  be 
geared  toward  systems  of  systems  not  single  systems. 

One  approach  that  has  been  suggested  to  support  network-centric  acquisition  is  the  use  of  portfo¬ 
lios.  Alberts  and  associates  describe  two  types  of  portfolios: 

DoD  needs  to  develop  investment  strategies  and  make  acquisition  decisions  based 
upon  portfolios.  [One  kind  is]  a  portfolio  or  package  of  investments  that  mirrors  a 
Mission  Capability  Package  [MCP] .  [Another  is]  an  infrastructure  portfolio  consist¬ 
ing  of  a  set  of  capabilities  necessary  to  support  multiple  MCPs  in  a  specific  area 
such  as  communications  [Alberts  1999]. 

One  type  of  portfolio  centers  on  an  MCP,  while  the  other  type  focuses  on  infrastructure  that 
would  support  multiple  MCPs.  Clearly,  the  integration  of  these  portfolios  must  also  be  accom¬ 
plished. 

Portfolio  management  can  be  a  mechanism  to  achieve  cost  reduction  by  ensuring  the  opportunity 
for  tradeoffs  among  important  choices  while  reducing  duplication  of  effort.  It  thusly  brings  the 
management  of  multiple  programs  under  a  common  framework  that  could  provide  the  necessary 
interoperability  in  a  network-centric  context. 

Although  a  portfolio-based  approach  is  expected  to  provide  benefit,  it  can  be  viewed  as  “just  an¬ 
other,  though  larger,  system.”  Systems  of  systems  are  accreted,  not  designed  as  a  single  mono¬ 
lithic  entity.  As  a  result,  the  acquisition  community  needs  to  make  its  processes  more  flexible  by, 
for  example,  placing  more  emphasis  on  a  more  rapid  and  decentralized  development  mode  or  in¬ 
cremental  acquisition. 

Whether  a  portfolio-based  approach  will  prove  viable  remains  to  be  seen;  other  approaches  yet  to 
be  devised  may  be  necessary.  In  any  event,  we  must  pay  attention  to  the  true  characteristics  of 
network-centric  systems,  such  as  their  degree  of  boundedness.  Those  practices  that  implicitly 
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place  a  bound  on  some  collection  of  systems,  such  as  the  use  of  MCP,  must  address  the  transition 
necessary  for  an  unbounded  situation. 
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4  Management  Practices 


Necessary  Condition 

Management  practices  are  sufficiently  defined  and  performed  to  enable  the  acquisition  of  systems 
of  systems. 

Rationale/Basis  for  this  Necessary  Condition 

Management  practices  involve  not  only  the  practices  used  in  procurement,  such  as  those  related  to 
cost  and  schedule,  but  also  practices  used  by  industry  in  the  construction  of  a  system.  All  of  those 
practices  must  contribute  to  achieving  the  goal  of  network-centric  operations,  rather  than  serving 
only  a  system-centric  perspective.  In  addition,  management  practices  need  to  be  formed  with  the 
recognition  that  multiple  constituents  are  involved  in  a  network-centric  environment.  The  many 
possible  interactions  among  those  constituents  are  likely  to  become  more  complex  in  the  un¬ 
bounded  environment  desired  by  the  operational  community. 

Discussion 

In  Section  3,  we  identified  a  need  for  the  legal  and  regulatory  enviromnent  to  support  acquisition 
in  a  network-centric  system  environment  more  effectively.  Management  practices  are  derived 
from  the  legal  and  regulatory  framework  that  governs  the  acquisition  and  development  processes. 
Given  a  change  to  the  legal  and  regulatory  environment,  there  must  be  a  corresponding  change  in 
the  practices  performed  by  management  agents,  whether  in  government  or  industry. 

Organizations  in  government  and  industry  perform  many  practices  in  an  acquisition,  such  as  those 
related  to  cost,  schedule,  risk  management,  and  system  engineering.  These  practices  are  employed 
by  project  management  entities  as  well  as  those  engaged  in  the  construction  of  a  system.  Different 
organizations  have  different  goals,  functions,  and  regulatory  constraints;  the  management  prac¬ 
tices  must  reflect  the  differences  in  constituencies. 

Management  practices  will  need  to  accommodate  various  facets  of  interoperability  such  as  the 
identification  and  establishment  of  communication  mechanisms  among  the  relevant  participants, 
the  sharing  of  information  (both  syntax  and  semantics),  and  the  behavior  expected  of  communi¬ 
cating  participants.  The  necessary  changes  must  extend  beyond  a  system-centric  perspective  to 
include  the  larger  context  of  interoperability  in  areas  such  as  the  following: 

•  Cost  management  must  realistically  account  for  integration  costs,  which  requires  understand¬ 
ing  those  needs  and  entering  agreements  about  how  those  needs  will  be  satisfied  and  funded. 
Current  regulations  often  delegate  integration  costs  to  a  particular  program  when,  in  fact,  in¬ 
tegration  costs — like  integration  itself — must  be  effectively  shared  and  managed  by  the  rele¬ 
vant  constituents. 

•  Schedule  management  must  account  for  dependencies  and  influences  among  the  participants. 
Appropriate  schedule  management  would  include  realistic  planning  and  interaction,  so  that  a 
shared  understanding  can  be  developed  and  agreed  to  [Meyers  2006b]. 
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•  Risk  management  must  account  for  risk  sharing  as  well  as  mitigation  planning  in  a  wider  con¬ 
text.  Note  the  connection  to  cost  here,  as  mitigation  planning  requires  resources  and  the 
source  of  such  resources  must  be  identified  and  potential  conflicts  resolved  [Meyers  2006c]. 

•  Various  practices  must  be  applied  to  assure  that  the  product  created  satisfies  its  performance 
goals,  from  verification  and  validation  through  user  acceptance  testing. 

Cost,  schedule,  risk,  and  performance  have  often  been  major  concerns  for  a  program  manager 
during  the  acquisition  of  a  single  system.  They  are  clearly  interrelated;  for  example,  schedule  is  a 
well-known  function  of  cost  (and  vice  versa).  In  a  network-centric  environment,  it  is  necessary  to 
effectively  manage  and  uncouple  the  many  possible  interactions  where  multiple  programs  and 
constituencies  may  be  involved.  Furthermore,  in  each  area,  the  problems  are  exacerbated  as  one 
moves  toward  an  unbounded  environment — as  the  operational  community  desires — posing  even 
more  challenges  to  the  management  of  systems  that  will  participate  in  a  network-centric  environ¬ 
ment.  In  addition  to  cost,  schedule,  risk,  and  performance,  other  subjects  must  be  addressed — 
such  as  governance,  which  is  discussed  in  Section  5. 

Finally,  the  role  of  the  operational  community  must  not  be  disregarded.  There  must  be  sufficient 
interaction  between  the  operational  community  and  the  communities  related  to  management  and 
construction  in  order  to  achieve  a  complete  success.  A  noteworthy  area  demanding  this  interaction 
is  requirements  management  [Meyers  2006a],  Integration  of  requirements  is  a  precursor  to  inte¬ 
gration  of  systems.  Also,  current  DoD  regulations  and  practices  account  for  Pre-Planned  Product 
Improvement  (P3I).  This  practice  must  account  for,  by  necessity,  the  larger  goal  of  achieving  in¬ 
teroperability  in  the  operational  context,  rather  than  providing  a  system-centric  perspective  solu¬ 
tion  to  a  perceived  local  problem  [Smith  2005]. 
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5  Governance  Procedures 


Necessary  Condition 

Governance  is  cooperative,  distributed  across  the  constituents,  and  applied  selectively. 

Rationale/Basis  for  this  Necessary  Condition 

As  system  developers  and  owners  realize  that  their  systems  are  component  systems  in  larger  sys¬ 
tems  of  systems,  they  will  gain  greater  understanding  of  the  need  for  new  governance  procedures. 
Beyond  understanding  the  need,  those  stakeholders  will  agree  on  what  governance  for  network¬ 
centric  systems  looks  like  and  practice  appropriate  governance  procedures.  The  primary  difficulty, 
and  crux  of  the  issue,  is  that  governance  (which  is  about  creation  and  enforcement  of  policy)  can 
truly  only  be  applied  to  those  things  that  an  individual  or  group  owns.  Network-centric  systems 
create  a  context  where  no  overarching  individual,  organization,  or  cooperative  body  owns  every¬ 
thing  and  can  thus  govern  everything.  We  can  go  further:  Even  if  it  were  possible  to  find  some 
individual  or  group  in  authority  to  own  all  the  related  systems,  there  are  too  many  of  those  sys¬ 
tems  to  control  or  even  comprehend  sufficiently  that  they  can  be  controlled  [Morris  2006], 

Discussion 

The  network-centric  environment  will  comprise  many  systems  loosely  coupled  together  by  a  net¬ 
work  such  as  the  Global  Information  Grid  (GIG)  and  capable  of  interacting  with  one  other  in  a 
variety  of  ways  to  serve  specific  purposes.  Owners  of  each  component  system  must  engage  in 
some  form  of  collaborative  governance  with  the  owners  of  closely  related  component  systems. 
Owners  must  share  governance  rather  than  dictate  it  to  one  other.  The  influence  by  individual 
constituents  in  the  shared  governance  will  depend  on  a  variety  of  factors  and  will  vary  with  time 
and  situation.  As  component  systems  become  increasingly  capable  of  interacting  with  one  other, 
they  will  often  participate  in  missions  for  which  they  were  not  originally  designed.  Thus,  the  own¬ 
ers  of  these  systems  will  need  to  cooperate,  in  terms  of  governance,  for  the  lifetime  of  such  mis¬ 
sions,  at  least.  Those  owners  may  have  no  formal  agreement  with  respect  to  governance,  yet  gov¬ 
ernance  must  still  be  effective.  To  complicate  matters  more,  it  is  conceivable — even  likely — that 
system  owners  will  find  themselves  simultaneously  participating  in  multiple  missions  and  inter¬ 
acting  with  different  collections  of  component  systems.  It  is  also  plausible  that,  in  some  cases,  the 
differing  mission  groups  will  agree  to  different  governance  processes,  complicating  governance 
further  for  the  system  in  the  middle. 

To  the  degree  that  governance  in  a  network-centric  environment  can  no  longer  be  about  strict  con¬ 
trol,  policy  must  be  created  and  enforced  based  on  peer-to-peer  cooperation  rather  than  hierarchi¬ 
cal  control.  Participants  thus  must  use  mechanisms  based  on  influence  and  persuasion  rather  than 
direct  authority.  Mechanisms  to  influence  others  to  do  the  right  thing  will  be  based  on  motivation 
or  accountability  through  visibility.  One  way  to  motivate  self-interest  is  to  make  owners  account¬ 
able  for  the  interoperability  (or  lack  thereof)  of  their  component  systems  by  exposing  data  on  ac- 
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tions  that  affect  interoperability.  With  such  data  available  and  visible,  individuals  will  be  moti¬ 
vated  (out  of  self-interest)  to  take  a  wider  rather  than  a  narrower  view.  In  addition  to  motivating 
the  development  and  operation  of  a  system  for  the  benefit  of  immediate  users,  network-centric 
operations  require  that  developers  be  motivated  by  some  notion  of  the  greater  good,  without  nec¬ 
essarily  knowing  what  that  greater  good  will  be  [Morris  2006]. 

An  obvious  consequence  of  the  network-centric  operational  environment  is  that  individual  sys¬ 
tems  will  be  changing  at  different  rates  and  times.  A  corollary  is  that  it  will  not  be  possible  to  co¬ 
ordinate  all  of  these  changes  to  provide  phased  increments  of  the  whole  system  of  systems.  As  a 
result,  we  see  a  greater  need  for  policies  with  respect  to  the  evolution  of  component  systems  both 
with  respect  to  their  general  interoperability  and  to  their  specialized  support  for  shared  global  ob¬ 
jectives.  In  essence,  governance  policies  will  define  the  etiquette  for  making  changes,  providing 
guidance  and  rules  for  what  must  be  done  to  inform  others  when  a  component  system  changes. 

It  is  clear  that  diffusion  rather  than  centralization  of  governance  is  called  for.  In  one  area,  how¬ 
ever,  there  will  be  a  tendency  toward  centralization:  the  infrastructure  supporting  the  system  of 
systems.  Specifically,  the  infrastructure  providers  will  define  the  standards  for  accessing  other 
systems,  such  as  the  nature  of  the  registries  or  metadata  repositories  and  even  the  communications 
protocols  supported.  However,  an  overly  restrictive  infrastructure  provider  will  likely  find  that  its 
expected  constituents  will  use  other  infrastructures  with  more  acceptable  governance.  It  is  incon¬ 
ceivable  that  there  could  be  one  infrastructure  to  support  all  of  network-centric  operations;  thus, 
there  is  a  need  for  policy  with  respect  to  missions  that  span  infrastructures. 

For  the  most  part,  these  points  about  network-centric  operations  argue  for  the  development  of 
governance  in  a  collaborative  peer-to-peer  fashion.  Yet,  they  likely  raise  other  questions.  What  is 
clear  is  that  governance  for  network-centric  operations  (whether  that  governance  is  applied  in  de¬ 
velopment  or  at  runtime)  will  differ  from  traditionally  understood  governance.  The  challenge  will 
be  to  develop  resolutions  to  the  issues  and,  subsequently,  measures  of  effectiveness  for  them. 
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6  Engineering  Practices 


Necessary  Condition 

Engineering  practices  appropriate  for  evolving  (including  developing)  systems  of  systems  are 
available,  widely  understood,  and  applied. 

Rationale/Basis  for  this  Necessary  Condition 

The  ability  to  create,  evolve,  test,  and  operate  network-centric  systems  requires  effective  engi¬ 
neering  practices  that  recognize  and  resolve  critical  aspects  of  systems  of  systems  that  contradict 
the  traditional  assumptions  that  systems  are  closed,  monolithic,  globally  visible,  centrally  control¬ 
lable,  or  stand  alone.  Appropriate  engineering  practices  must  be  developed,  validated,  and  used  to 
evolve  systems  in  a  context  of  understanding  systems  of  systems. 

Discussion 

Traditional  engineering  practices  assume  that 

•  Need  and  intended  use  are  known. 

•  Development  is  within  the  control  of  a  single  individual  or  organization. 

•  Requirements  are  known  and  unchanging.9 

•  Systems  have  clearly  defined  boundaries  with  known  external  parameters  or  interfaces  and 
explicitly  specified  interface  standards. 

Engineering  practices  based  on  these  assumptions  have  proven  effective  in  the  development,  test¬ 
ing,  and  integration  of  stand-alone  systems  for  several  decades.  They  remain  effective  for  many  of 
the  parts  of  systems  of  systems,  but  for  systems  of  systems  as  a  whole,  they  are  often  counterpro¬ 
ductive  in  achieving  interoperability.  The  assumptions  were,  of  course,  always  simplifications; 
but  they  have  been  sufficiently  accurate  for  most  applications  of  traditional  systems. 

Increasingly,  owners  of  network-centric  systems  must  undertake  integration  and  integration  test¬ 
ing  of  their  own  systems.  Defense  contractors  are  often  unwilling  to  assume  responsibility  for 
integration  and  system-wide  testing.  They  continue  to  develop  and  test  system  components  for 
which  traditional  engineering  practices  are  applicable,  but  they  decline  to  undertake  integration 
activities  for  which  no  established  engineering  practices  have  proven  effective.  The  underlying 
issue  is  that  systems  of  systems  cannot  be  integrated  in  the  traditional  sense;  instead,  they  must  be 
composed  of  constituent  parts  that  are  capable  of  interoperating  with  each  other  under  varying  and 
sometimes  unanticipated  conditions. 


9  Actual  end-user  needs  evolve  even  during  development,  but  current  engineering  practices  are  not  designed  to  deal  with 
continuous  evolution  and  either  ignore  such  changes  or  treat  them  as  discrete  modifications  to  static  goals. 
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Some  unique  and  previously  unaddressed  aspects  of  system-of-systems  engineering  practices  re¬ 
late  to  systems  of  systems  as  a  whole  and  not  to  their  constituent  components.  Component  sys¬ 
tems  typically  are  closed  systems  with  known  boundaries  and  clearly  defined  functionality.  Their 
development  can  be  centrally  controlled  with  all  details  and  aspects  of  the  development  visible. 
Consequently,  the  components  or  constituents  of  a  system  of  systems  can  be  individually  devel¬ 
oped  within  the  regime  of  traditional  engineering  practices  providing  each  is  designed  to  interop¬ 
erate  in  a  system-of-systems  context.  Unfortunately,  at  the  systems-of-systems  level  of  network¬ 
centric  systems,  traditional  practices  are  inappropriate  because  of  the  increased  complexity,  the 
necessity  for  distributed  control,  the  presence  of  independent  decision  making  by  multiple  con¬ 
stituents,  the  potential  for  difficult-to-envision  indirect  effects  and  emergent  behavior,  the  need  to 
evolve  objectives  continuously  throughout  development,  and  the  absence  of  total  system  perspec¬ 
tive  that  can  be  used  for  end-to-end  test  and  evaluation.  Furthermore,  the  situation  is  aggravated 
by  lack  of  operational  perspective  during  development. 

New  engineering  practices  are  needed  that  are  founded  on  an  understanding  of  system-of-systems 
characteristics,  applicable  to  networked  systems,  and  demonstrably  effective.  Both  development 
and  acceptance  of  these  practices  will  be  difficult,  because  they  not  only  involve  new  paradigms 
but  also  are  likely  to  be  in  direct  conflict  with  conventional  training  and  intuition  derived  for 
monolithic  systems.  The  necessity  for  development  and  operation  in  the  presence  of  uncertainty, 
the  need  for  dynamic  adaptability  to  unforeseen  situations,  the  ineffectiveness  of  centralized  con¬ 
trol,  and  the  inability  to  avoid  emergent  effects — all  require  radically  different  engineering  ap¬ 
proaches  in  the  design,  implementation,  and  evolution  of  systems  of  systems.  Those  approaches 
should  adhere  to  principles  such  as  the  following: 

•  Engineering  practices  for  network-centric  systems  must  emphasize  flexibility  and  adaptability 
over  local  optimization. 

•  Designs  must  avoid  the  single  points  of  system  failure  inherent  in  hierarchical  structures.  If 
none  of  the  monolithic  constituents  of  a  system  of  systems  is  critical  to  the  system  as  a  whole, 
then  single  points  of  failure  within  a  given  constituent  are  likewise  noncritical. 

•  The  traditional  concept  of  static,  rarely  changing  requirements  must  give  way  to  the  capacity 
to  envision  use  from  an  operational  perspective  in  a  dynamic,  uncertain  world  of  continuously 
changing  needs  in  which  systems  must  dynamically  adapt  to  unforeseen  circumstances. 

•  Emergent  effects  must  be  understood,  their  ill  effects  avoided,  and  their  benefits  exploited  to 
advantage. 

•  The  focus  must  change  from  maximizing  the  number  of  available  features  to  optimizing  long¬ 
term  satisfaction  of  evolving  operational  needs. 

As  a  practical  matter,  engineering  practices  appropriate  for  systems  of  systems  should  be  devel¬ 
oped  incrementally,  as  a  growing  and  evolving  body  of  knowledge  is  widely  shared  and  increas¬ 
ingly  used.  The  practices  should  be  codified  by  situation,  tradeoff  benefit,  and  risk.  Practices 
should  serve  as  a  source  book  and  generalized  plan  for  development  and  evolution  of  all  DoD 
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network-centric  systems.  Special  care  must  be  exercised  to  ensure  that  engineering  practices 
based  on  conflicting  assumptions  are  not  applied  in  combination. 
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7  Technology  Base 


Necessary  Condition 

A  technology  base  exists  that  is  capable  of  realizing  the  network-centric  vision. 

Rationale/Basis  for  this  Necessary  Condition 

The  vision  of  network-centric  operations  places  considerable  emphasis  on  technologies.  These 
technologies  range  from  infrastructure  considerations  (faster  networks  throughout  the  operational 
environment)  to  applications  that  incorporate  implementations  of  concepts  such  as  a  common  op¬ 
erational  picture  and  sophisticated  decision  aids.  Those  involved  in  acquisition  and  construction 
of  systems  designed  to  participate  in  a  network-centric  environment  should  leverage  the  technol¬ 
ogy  base  in  different  ways  than  in  the  past,  such  as  by  keeping  abreast  of  communication  and  in¬ 
creasing  the  speed  of  technology  acquisition. 

Discussion 

Realizing  the  network-centric  vision  depends  heavily  on  technologies  to  provide  the  necessary 
capabilities  to  the  operational  community.  The  technologies  are  often  discussed  relative  to  the 
infrastructure — faster  processors,  faster  and  more  mobile  networks.  However,  providing  software 
technologies  that  meet  the  network-centric  needs  offers  a  considerable  challenge.  The  infrastruc¬ 
ture  provides  the  physical  connectivity,  and  the  software  takes  advantage  of  it. 

Although  the  DoD  has  relied  on  the  products  (and  services)  of  the  technology  base  for  a  long 
time,  there  are  changes  to  consider  for  network-centric  operations.  In  particular,  network-centric 
operations  require  a  focus  on  technologies  that  can  be  used  in  the  integration  of  systems — in  the 
extreme  case,  dynamic  integration  of  systems  that  are  not  known  prior  to  deployment. 

The  network-centric  vision  includes  many  concepts,  one  of  which  deals  with  the  ability  of  “any 
actor  to  task  any  effector.”  Achieving  that  ability  requires  consideration  of  remote  management. 
Thus,  today’s  components,  centrally  managed,  will  need  to  become  distributed,  managed  objects 
capable  of  being  shared  across  a  wide  environment.  There  is  therefore  a  need  to  perform  remote 
management,  with  the  corresponding  need  for  specification  of  managed  objects,  service-level 
agreements,  protocols,  and  so  on.  Associated  with  this  problem,  there  are  others.  For  example,  a 
request  to  a  sensor  might  require  that  the  schedulability  of  that  sensor  be  addressed  during  the 
course  of  execution.  Correspondingly,  recognition  and  resolution  of  conflicts  among  competing 
interests  must  be  accounted  for. 

The  preceding  is  but  one  example  of  a  technology  that  will  be  required  to  achieve  the  vision  of 
network-centric  operations.  Many  other  examples  exist,  such  as  technologies  that  affect  the  distri¬ 
bution  of  information  (perhaps  in  the  real-time  domain)  or  virtual  collaboration  among  disparate 
organizations. 
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To  encourage  power  to  the  edge,  decision  aids  will  become  important.  Such  decision  aids  can  in¬ 
clude  tools  to  provide  assessment  of  the  (local)  environment  (i.e.,  common  operational  picture), 
recommend  courses  of  action  (such  as  automated  planning  and  automated  doctrine),  or  initiate 
and  perform  operations  independent  of  a  human.  The  growing  importance  of  decision  aids  reflects 
the  need  for  more  autonomy  by  the  components  in  the  operational  environment.  In  turn,  this  need 
leads  to  the  desire  for  more  decision  aid  tools,  such  as  automated  doctrine  (a  concept  realized  in 
the  impetus  for  more  robotic  objects).  In  the  network-centric  context,  the  challenge  to  developing 
the  necessary  technologies  posed  by  autonomous  behavior  embedded  in  a  robot  capable  of  dealing 
with  information  on  a  broad  scale  is  considerable. 

The  desire  for  more  dynamics  in  the  operational  environment  implies  that  such  dynamism  be  ad¬ 
dressed  throughout  development  (e.g.,  dynamic  scheduling  and  management).  The  ability  to  ad¬ 
dress  semantics  in  a  dynamic  environment  is  related  to  this  issue.  In  a  dynamic  environment,  the 
semantics  of  information — and  perhaps  of  operations  as  well — will  change  over  time.  This  line  of 
thought  can  continue  to  where  consideration  of  dynamic  behavior  becomes  a  goal  unto  itself.  How 
can  a  behavior  of  a  system  be  changed  during  its  own  execution?  What  are  the  technologies  nec¬ 
essary  to  manage  dynamic  behavior? 

The  technology  base  for  network-centric  operations  will  come  primarily  from  industry.  This  cir¬ 
cumstance  requires  knowledge  of  the  industry  community  and  the  ability  to  leverage  results  of  the 
technology  base  improvements.  Network-centric  considerations  warrant  that  the  DoD  examine  the 
technology  base  now  from  that  perspective.  It  is  possible  to  spur  necessary  research  in  network¬ 
centric  problems  through  organizations  such  as  the  Defense  Advanced  Research  Projects  Agency 
(DARPA)  and  service-oriented  research  programs  including  the  Army  Research  Office  (ARO), 
Office  of  Naval  Research  (ONR),  and  the  Air  Force  Office  of  Scientific  Research  (AFOSR).  In 
addition,  because  of  the  increased  need  to  interoperate  on  a  wider  scale,  there  may  be  a  need  to 
widen  technology  base  considerations  correspondingly.  In  particular,  technology  base  considera¬ 
tions  may  warrant  leveraging  technologies  developed  by  coalition  partners.  As  interoperability 
continues  to  gain  increased  importance,  we  anticipate  a  corresponding  importance  in  interopera¬ 
bility  through  the  various  organizations  that  contribute  to  the  technology  base. 

However,  some  of  the  anticipated  technological  approaches  are  either  immature  (such  as  agent- 
based  approaches  or  service-oriented  architecture)  or  may  not  yet  exist.  In  many  cases,  the  desired 
technologies  have  not  been  demonstrated  on  the  envisioned  scale  of  a  system  of  systems.  Toward 
this  end,  there  would  be  utility  in  examining  technology  readiness  levels  to  include  a  dimension  of 
applicability  of  the  technology  to  be  used  in  a  network-centric  enviromnent.  Further,  the  ability  to 
demonstrate  the  accrual  of  systems  to  a  system-of-systems  context,  perhaps  through  simulation,  is 
a  worthy  effort. 

There  must  be  a  way  to  incorporate  the  technology  base  in  the  acquisition  context,  notably 
through  contracts.  One  way  that  this  can  occur  is  for  future  procurement  to  include  technical  fea¬ 
sibility  as  a  key  contractual  aspect.  One  might  expect  that  future  acquisitions  will  place  greater 
emphasis  on  the  ability  to  address  specifically  the  network-centric  context,  including  the  ability  to 
integrate  possibly  unknown  sources  in  a  dynamic  context.  Doing  so  adds  increased  difficulty  for 
the  specification  and  evaluation  of  proposals,  not  to  mention  the  development  of  products. 
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Finally,  technology  base  considerations  must  be  seriously  considered  by  the  acquisition  commu¬ 
nity  itself.  For  example,  what  areas  of  schedule  management  or  risk  management  could  benefit 
from  increased  technological  support?  In  particular,  there  is  a  need  for  technologies  that  provide 
greater  sharing  of  information,  including  semantics,  as  well  as  operation  on  that  shared  informa¬ 
tion.  Because  the  principles  of  network-centric  operation  apply  to  both  the  acquisition  and  opera¬ 
tional  communities,  the  need  for  technologies  to  enact  those  principles  does,  too. 
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8  Summary 


The  effectiveness  of  systems  of  systems  is  influenced  by  their  social  and  cultural  environment, 
legal  and  regulatory  framework,  management  practices,  governance  procedures,  engineering  prac¬ 
tices,  and  technology  base.  In  those  areas,  new  practices  and  tools  are  needed  to  effectively  ac¬ 
quire,  develop,  test,  and  operate  network-centric  systems  of  systems.  The  new  practices  and  tools 
must  be  built  on  assumptions  that  recognize  system-of-systems  characteristics — such  as  inde¬ 
pendent  development  and  independent  management  of  constituents  parts,  continuous  evolution  of 
operational  needs,  often  undesirable  emergent  behavior,  necessity  of  interoperation  with  both  un¬ 
anticipated  and  legacy  systems,  and  the  need  for  adaptation  to  unforeseen  situations  (see  Figure 
3). 
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Syste  m-of-Syste  m  s 
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Figure  3:  Application  of  Practices  Grounded  in  Assumptions  that  Recognize  System-of-Systems  Realities 

In  this  report,  we  introduced  a  necessary  condition  to  which  each  of  those  areas  must  evolve. 
While  positioning  these  conditions  as  the  desired  future  states,  we  note  that  evolution  to  them  will 
be  gradual  and  occur  at  different  rates.  (See  Table  3.)  The  next  steps  should  include  short-term 
efforts  that  move  in  the  direction  of  the  identified  conditions  for  achieving  network-centric  opera¬ 
tions  in  systems  of  systems.  The  current  conditions  also  could  be  refined  and  extended  to  addi¬ 
tional  dimensions,  but  such  efforts  will  likely  have  only  incremental  benefit.  Most  needed  is  an 
idealized  vision  of  how  systems  of  systems  can  and  should  be  acquired,  developed,  evolved,  and 
operated  in  the  21st  century.  The  vision  need  not  be  instantiated  in  detail  but  must  account  for  all 
critical  aspects  of  systems  of  systems  and  must  encompass  a  full  spectrum  of  business  and  techni¬ 
cal  concerns. 
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Table  3:  Evolution  Toward  Some  Necessary  Conditions  for  Network-Centric  Operations  in  Systems  of 
Systems 


Area  of  Significance 

Necessary  Condition 

Incremental  Objective 

Social  and  cultural 
environment 

The  social  and  cultural  environment  in 
which  systems  of  systems  are  acquired, 
developed,  used,  and  evolved  motivates 
collaborative  behavior  critical  to  achieving 
operational  effectiveness. 

Eliminate  aspects  of  the  current 
social  and  cultural  environment  that 
serve  as  barriers  to  achieving  nec¬ 
essary  reforms  in  other  areas. 

Legal  and 
regulatory 
framework 

There  exists  a  legal  and  regulatory 
framework  to  support  the  acquisition  of 
systems  of  systems. 

Interpret  or  modify  the  legal  and 
regulatory  framework  to  better  sup¬ 
port  systems  of  systems. 

Management 

practices 

Management  practices  are  sufficiently 
defined  and  performed  to  enable  the  ac¬ 
quisition  of  systems  of  systems. 

Increase  interaction  between  the 
operational  community  and  the 
communities  related  to  manage¬ 
ment  and  construction. 

Governance 

procedures 

Governance  is  cooperative,  distributed 
across  the  constituents,  and  applied  se¬ 
lectively. 

Aim  to  develop  resolutions  to  issues 
and  measures  of  effectiveness. 

Engineering 

practices 

Engineering  practices  appropriate  for 
evolving  (including  developing)  systems  of 
systems  are  available,  widely  understood, 
and  applied. 

Develop  engineering  practices  ap¬ 
propriate  for  systems  of  systems 
incrementally. 

Technology  base 

A  technology  base  exists  that  is  capable 
of  delivering  the  realization  of  the  network¬ 
centric  vision. 

Develop  a  technology  base  that  can 
address  the  dynamic,  evolving,  un¬ 
certain,  and  emergent  aspects  of 
systems  of  systems,  as  well  as  their 
monolithic  components. 

In  examining  the  necessary  conditions,  we  formed  several  themes  that  might  also  be  worthy  of 

further  investigation.  Among  those  themes  are  the  following: 

•  Successful  transformation  of  the  DoD  acquisition  system  requires  a  broader  approach.  The 
operational  community  desires  integrated  capabilities  to  meet  a  mission,  but  the  acquisition 
community  is  focused  on  delivering  a  system-oriented  solution. 

•  There  must  be  sufficient  interaction  between  the  operational  community  and  the  communities 
related  to  management  and  construction  to  achieve  complete  success. 

•  Traditional  engineering  practices  and  governance  procedures  are  often  counterproductive  for 
achieving  interoperability,  when  they  are  used  in  combination  in  systems  of  systems.  They 
are  based  on  assumptions  that  do  not  reflect  the  reality  of  larger,  more  complex,  and  net¬ 
worked  systems  of  systems. 

•  The  disparity  between  traditional  assumptions  and  the  realities  of  systems  of  systems  is  no 
longer  one  of  degree  or  variation  but  often  one  of  fundamental  conflicts.  Practices  and  proce¬ 
dures  that  are  effective  for  network-centric  systems  of  systems  will  likely  conflict  with  cur¬ 
rent  system  acquisition  and  development  practices  that  are  built  on  assumptions  that  are  no 
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longer  valid.  This  problem  exists  not  only  for  modem  systems  of  systems  but  also  for  the  so¬ 
cial  and  cultural  contexts  that  acquire,  develop,  evolve,  and  operate  them. 

The  social  and  cultural  environment  of  a  network-centric  system  includes  emergent  effects 
that  emanate  from  the  constituents’  engineering  practices,  governance  preferences,  manage¬ 
ment  practices,  and  legal  and  regulatory  framework — as  well  as  from  the  technology  base. 


SOFTWARE  ENGINEERING  INSTITUTE  |  25 


References 


[Alberts  1999] 

Alberts,  David  S.;  Garstka,  John  J.;  &  Stein,  Frederick  P.  Network  Centric  Warfare:  Developing 
and  Leveraging  Information  Superiority.  Washington,  DC:  CCRP  Publication  Series,  1999. 

[Alberts  2003] 

Alberts,  David  S.  &  Fiayes,  Richard  E.  Power  to  the  Edge:  Command  and  Control  in  the  Informa¬ 
tion  Age.  Washington,  DC:  CCRP  Publication  Series,  2003. 

[Brownsword  2004] 

Brownsword,  Lisa  L.;  Carney,  David  J.;  Fisher,  David;  Lewis,  Grace;  Meyers,  Craig;  Morris, 
Edwin  J.;  Place,  Patrick  R.  H.;  Smith,  James;  &  Wrage,  Lutz.  Current  Perspectives  on  Interop¬ 
erability  (CMU/SEI-2004-TR-009,  ADA421613).  Pittsburgh,  PA:  Software  Engineering  Institute, 
Carnegie  Mellon  University,  2004. 

http://www.sei.cmu.edu/publications/documents/04.reports/04tr009.html. 

[Brownsword  2006] 

Brownsword,  L.;  Fisher,  D.;  Morris,  E.;  Smith,  J.;  &  Kirwan,  P.  System-of-Systems  Navigator:  An 
Approach  for  Managing  System-of-Systems  Interoperability  (CMU/SEI-2006-TN-019).  Pitts¬ 
burgh,  PA:  Software  Engineering  Institute,  Carnegie  Mellon  University,  2006. 
http://www.sei.cmu.edu/publications/documents/06.reports/06tn019.html. 

[Carney  2005a] 

Carney,  D.;  Fisher,  D.;  &  Place,  P.  Topics  in  Interoperability:  System-of-Systems  Evolution 
(CMU/SEI-2005-TN-002).  Pittsburgh,  PA:  Software  Engineering  Institute,  Carnegie  Mellon  Uni¬ 
versity,  2005.  http://www.sei.cmu.edu/publications/documents/05.reports/05tn002.html. 

[Carney  2005b] 

Carney,  D.;  Fisher,  D.;  Morris,  E.;  &  Place,  P.  Some  Current  Approaches  to  Interoperability 
(CMU/SEI-2005-TN-033,  ADA441828).  Pittsburgh,  PA:  Software  Engineering  Institute,  Carne¬ 
gie  Mellon  University,  2005. 

http://www.sei.cmu.edu/publications/documents/05.reports/05tn033.html. 

[Carney  2005c] 

Carney,  D.;  Smith,  J.;  &  Place,  P.  Topics  in  Interoperability :  Infrastructure  Replacement  in  a  Sys¬ 
tem  of  Systems  (CMU/SEI-2005-TN-031,  ADA444901).  Pittsburgh,  PA:  Software  Engineering 
Institute,  Carnegie  Mellon  University,  2005. 

http://www.sei.cmu.edu/publications/documents/05.reports/05tn031.html. 

[Carney  2005d] 

Carney,  D.;  Anderson,  W.;  &  Place,  P.  Topics  in  Interoperability:  Concepts  of  Ownership  and 
Their  Significance  in  Systems  of  Systems  (CMU/SEI-2005-TN-046,  ADA447053).  Pittsburgh,  PA: 
Software  Engineering  Institute,  Carnegie  Mellon  University,  2005. 
http://www.sei.cmu.edu/publications/documents/05.reports/05tn046.html. 


26  |  CMU/SEI-2007-TN-003 


[Christie  2002] 

Christie,  A.  Network  Survivability  Analysis  Using  Easel  (CMU/SEI-2002-TR-039,  ADA4 13664). 
Pittsburgh,  PA:  Software  Engineering  Institute,  Carnegie  Mellon  University,  2002. 
http://www.sei.cmu.edu/publications/documents/02.reports/02tr039.html. 

[Ellison  1997] 

Ellison,  B.;  Fisher,  D.  A.;  Linger,  R.  C.;  Lipson,  H.  F.;  Longstaff,  T.;  &  Mead,  N.  R.  Survivable 
Network  Systems:  An  Emerging  Discipline  (CMU/SEI-97-TR-013,  ADA341963).  Pittsburgh,  PA: 
Software  Engineering  Institute,  Carnegie  Mellon  University,  1997. 
http://www.sei.cmu.edu/publications/documents/97.reports/97tr013/97tr013abstract.html. 

[Fisher  1999] 

Fisher,  D.  A.  &  Lipson,  H.  F.  “Emergent  Algorithms — A  New  Method  for  Enhancing  Survivabil¬ 
ity  in  Unbounded  Systems,”  Volume  Track  7.  Proceedings  of  32nd  Hawaii  International  Confer¬ 
ence  on  Systems  Sciences  (HICCS-32).  Maui,  HI,  January  5-8,  1999.  Digital  Object  Identifier 
10.1 109/HICSS.  1999.772824. 

[Fisher  2006] 

Fisher,  D  .An  Emergent  Perspective  on  Interoperation  in  Systems  of  Systems  (CMU/SEI-2006- 
TR-003).  Pittsburgh,  PA:  Software  Engineering  Institute,  Carnegie  Mellon  University,  2006. 
http://www.sei.cmu.edu/publications/documents/06.reports/06tr003.html. 

[Lewis  2004a] 

Lewis,  Grace;  Mahatham,  Teeraphong;  &  Wrage,  Lutz.  Assumptions  Management  in  Software 
Development  (CMU/SEI-2004-TN-021).  Pittsburgh,  PA:  Software  Engineering  Institute,  Carnegie 
Mellon  University,  2004. 

http://www.sei.cmu.edu/publications/documents/04.reports/04tn021.html. 

[Lewis  2004b] 

Lewis,  Grace  A.;  Morris,  Edwin  J.;  &  Wrage,  Lutz.  Promising  Technologies  for  Future  Systems 
(CMU/SEI-2004-TN-043).  Pittsburgh,  PA:  Software  Engineering  Institute,  Carnegie  Mellon  Uni¬ 
versity,  2004.  http://www.sei.cmu.edu/publications/documents/04.reports/04tn043.html. 

[Lewis  2004c] 

Lewis,  G.  &  Wrage,  L.  Approaches  to  Constructive  Interoperability  (CMU/SEI-2004-TR-020). 
Pittsburgh,  PA:  Software  Engineering  Institute,  Carnegie  Mellon  University,  2004. 
http://www.sei.cmu.edu/publications/documents/04.reports/04tr020.html. 

[Lipson  1999] 

Lipson,  Howard  &  Fisher,  David.  “Survivability — A  New  Technical  and  Business  Perspective  on 
Security,”  33-39.  Proceedings  of  the  1999  New  Security  Paradigms  Workshop.  Caledon  Hills, 
Ontario,  Canada,  September  22-24,  1999.  New  York,  NY:  Association  for  Computing  Machin¬ 
ery,  2000.  http://www.cert.org/archive/pdf/busperspec.pdf. 

[Lutz  2000  ] 

Lutz,  R.  L.  “Software  Engineering  for  Safety:  A  Roadmap,”  215-224.  The  Future  of  Software 
Engineering.  New  York,  NY:  ACM  Press,  2000  (ISBN  1-58113-253-0).  Available  at 
http://www.cs.ucl.ac.Uk/staff/A.Finlcelstein/fose/finallutz.pdf. 


SOFTWARE  ENGINEERING  INSTITUTE  |  27 


[Maier  96] 

Maier,  M.  “Architecting  Principles  for  Systems-of-Systems,”  567-574.  Proceedings  of  the  Sixth 
Annual  International  Symposium  ofINCOSE.  Boston,  MA,  July  7—11,  1996.  Boston,  MA: 
INCOSE,  1996.  http://www.infoed.com/Open/PAPERS/systems.htm. 

[Meyers  2001] 

Meyers,  B.  &  Oberndorf,  P.  A  Framework  for  the  Specification  of  Acquisition  Models  (CMU/SEI- 
2001-TR-004,  ADA401717).  Pittsburgh,  PA:  Software  Engineering  Institute,  Carnegie  Mellon 
University,  200 1 .  http://www.sei.cmu.edU/publications/documents/0 1  .reports/0 1  tr004.html. 

[Meyers  2005] 

Meyers,  B.;  Monarch,  I.;  Levine,  L.;  &  Smith,  J.  Including  Interoperability  in  the  Acquisition 
Process  (CMU/SEI-2005-TR-004).  Pittsburgh,  PA:  Software  Engineering  Institute,  Carnegie  Mel¬ 
lon  University,  2005.  http://www.sei.cmu.edu/publications/documents/05.reports/05tr004.html. 

[Meyers  2006a] 

Meyers,  B.;  Smith,  J.;  Capell,  P.;  &  Place,  P.  Requirements  Management  in  a  Svstem-of-Systems 
Context:  A  Workshop  (CMU/SEI-2006-TN-015).  Pittsburgh,  PA:  Software  Engineering  Institute, 
Carnegie  Mellon  University,  2006. 

http://www.sei.cmu.edu/publications/documents/06.reports/06tn015.html. 

[Meyers  2006b] 

Meyers,  B.  C.  &  Sledge,  C.  A.  Schedule  Considerations  for  Interoperable  Acquisition  (CMU/SEI- 
2006-TN-035).  Pittsburgh,  PA:  Software  Engineering  Institute,  Carnegie  Mellon  University, 

2006.  http://www.sei.cmu.edu/publications/documents/06.reports/06tn035.html. 

[Meyers  2006c] 

Meyers,  B.  C.  Risk  Management  Considerations  for  Interoperable  Acquisition  (CMU/SEI-2006- 
TN-032).  Pittsburgh,  PA:  Software  Engineering  Institute,  Carnegie  Mellon  University,  2006. 
http://www.sei.cmu.edu/publications/documents/06.reports/06tn032.html. 

[Moffat  2003] 

Moffat,  James.  Complexity  Theory  and  Network  Centric  Warfare.  Washington,  DC:  CCRP  Publi¬ 
cation  Series,  2003. 

[Morris  2004] 

Morris,  Edwin;  Levine,  Linda;  Meyers,  Craig;  Place,  Pat;  &  Plakosh,  Dan.  Systems  of  Systems 
Interoperability  (SOSI);  Final  Report  (CMU/SEI-2004-TR-004,  ADA455619).  Pittsburgh,  PA: 
Software  Engineering  Institute,  Carnegie  Mellon  University,  2004. 
http://www.sei.cmu.edu/publications/documents/04.reports/04tr004.html. 

[Morris  2006] 

Morris,  Ed;  Place,  Pat;  &  Smith,  Dennis.  System-of-Systems  Governance: 

New  Patterns  of  Thought  (CMU/SEI-2006-TN-036).  Pittsburgh,  PA:  Software  Engineering  Insti¬ 
tute,  Carnegie  Mellon  University,  2006. 

http://www.sei.cmu.edu/publications/documents/06.reports/06tn036.html. 


28  |  CMU/SEI-2007-TN-003 


[Rumsfeld  2002] 

Rumsfeld,  Donald.  Testimony  OfU.S.  Secretary  Of  Defense  Donald  H.  Rumsfeld 
2002  Defense  Department  Amended  Budget  Thursday,  June  28,  2001. 
http://www.defenselinlc.mi  l/Speeches/Speech.aspx?SpeechID=384. 

[Smith  2005] 

Smith  II,  J.  &  Meyers,  B.  Exploring  Programmatic  Interoperability:  Army  Future  Force  Work¬ 
shop  (CMU/SEI-2005-TN-042,  ADA443482).  Pittsburgh,  PA:  Software  Engineering  Institute, 
Carnegie  Mellon  University,  2005. 

http://www.sei.cmu.edu/publications/documents/05.reports/05tn042.html. 

[Smith  2006] 

Smith  II,  James  D.  Topics  in  Interoperability:  Structural  Programmatics  in  a  System  of  Systems 
Interoperable  Acquisition  Challenges  (CMU/SEI-2006-TN-037).  Pittsburgh,  PA:  Software  Engi¬ 
neering  Institute,  Carnegie  Mellon  University,  2006. 
http://www.sei.cmu.edu/publications/documents/06.reports/06tn037.html. 

[USC  2004] 

United  States  Code.  Title  10 — Armed  Forces,  http://www.access.gpo.gov/uscode 
/title  1 0/subtitlea_.html  (2004). 


SOFTWARE  ENGINEERING  INSTITUTE  |  29 


REPORT  DOCUMENTATION  PAGE 

Form  Approved 

OMB  No.  0704-0188 

Public  reporting  burden  for  this  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  search¬ 
ing  existing  data  sources,  gathering  and  maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments 
regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information,  including  suggestions  for  reducing  this  burden,  to  Washington  Head¬ 
quarters  Services,  Directorate  for  information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington,  VA  22202-4302,  and  to  the 
Office  of  Management  and  Budget,  Paperwork  Reduction  Project  (0704-0188),  Washington,  DC  20503. 

1.  AGENCY  USE  ONLY 

(Leave  Blank) 

2.  REPORT  DATE 

January  2007 

3.  REPORT  TYPE  AND  DATES 

COVERED 

Final 

4.  TITLE  AND  SUBTITLE 

Conditions  for  Achieving  Network-Centric  Operations  In  Systems  of  Systems 

5.  FUNDING  NUMBERS 

FA8721-05-C-0003 

6.  AUTHOR(S) 

David  A.  Fisher,  B.  Craig  Meyers,  Pat  Place 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Software  Engineering  Institute 

Carnegie  Mellon  University 

Pittsburgh,  PA  15213 

8.  PERFORMING  ORGANIZATION 

REPORT  NUMBER 

CMU/SEI-2007-TN-003 

9.  SPONSORING/MONITORING  AGENCY  NAIVE(S)  AND  ADDRESS(ES) 

HQ  ESC/XPK 

5  Eglin  Street 

Hanscom  AFB,  MA  01731-21 16 

10.  SPONSORING/MONITORING 

AGENCY  REPORT  NUMBER 

11.  SUPPLEMENTARY  NOTES 

12A  DISTRIBUTION/ AVAILABILITY  STATEMENT 

Unclassified/Unlimited,  DTIC,  NTIS 

12B  DISTRIBUTION  CODE 

13.  ABSTRACT  (MAXIMUM  200  WORDS) 

The  advantages  of  systems  of  systems— such  as  the  ability  to  adapt  to  unanticipated  and  unforeseen  situations,  eliminate  single  points 
of  failure,  and  remain  continuously  operational  while  being  dynamically  updated— guarantee  their  increasing  importance  to  military  and 
commercial  environments.  The  advent  of  network-centric  systems  has  served  only  to  accelerate  the  already  prevalent  move  toward 
systems  of  systems. 

At  the  same  time,  network-centric  systems  and  systems  of  systems  are  proving  difficult  to  acquire,  develop,  test,  and  operate.  Many  of 
them  are  abandoned  before  they  can  be  fielded,  and  fielded  systems  often  fail  to  satisfy  their  objectives— demonstrating  cost  and 
schedule  overruns  in  their  development  and  sometimes  catastrophic  failures  in  operation. 

The  increasing  disparity  between  the  normative  (but  nonfactual)  assumptions  that  underlie  current  practices  and  tools  used  in  the  ac¬ 
quisition,  development,  evolution,  and  operation  of  systems  and  the  realities  of  actual  systems  of  systems  contributes  to  those  prob¬ 
lems.  Effective  practices  and  tools  for  the  acquisition,  development,  and  operation  of  systems  of  systems  have  not  yet  been  developed. 
Suggesting  a  context  in  which  those  practices  and  tools  can  be  developed,  this  technical  note  proposes  necessary  conditions — 
statements  of  what  the  desired  future  state  should  be— in  six  areas  that  influence  the  effectiveness  of  network-centric  systems  and  sys¬ 
tems  of  systems:  (1 )  social  and  cultural  environment,  (2)  legal  and  regulatory  framework,  (3)  management  practices,  (4)  governance 
procedures,  (5)  engineering  practices,  and  (6)  technology  base. 


14.  SUBJECT TEFIMIS 

Network  centric  operations,  net  centric  operations,  system  of  systems,  systems  of  systems, 

SoS 

15.  NUMBER  OF  PAGES 

40 

16.  PRICECODE 

17.  SECURITY  CLASSIFICATION  OF 

18.  SECURITY  CLASSIFICATION 

19.  SECURITY 

20.  LIMITATION  OF 

REPORT 

OF  IRIS  PAGE 

CLASSIFICATION  OF 

ABSTRACT 

Unclassified 

Unclassified 

ABSTRACT 

Unclassified 

UL 

NSN  7540-01-280-5500  Standard  Form  298  (Rev.  2-89)  Prescribed  by  ANSI  Std.  Z39-18 


298-102 


